Cassandra is designed to support running multiple nodes in a cluster. It is entirely possible to deploy only a single node (though many of Cassandra's features cannot be utilized). More over RHQ fully supports deploying a single storage node. This document covers configuration and maintenance of a single node deployment.
The information on this page is specific to a single node deployment.
Read repair should be run as a regularly scheduled maintenance operation to ensure data is consistent across replicas (i.e., nodes that own a particular range of keys) in the cluster. With a only single node, there is no need to run read repair.
gc_grace_seconds is a table attribute that specifies the time to wait before garbage collecting tombstones (i.e., deletions). This allows for consistency to be achieved prior to deletion. For a single node cluster, gc_grace_seconds can be set to zero for each table.
Replication is one of the key features of Cassandra. There is no replication with a single node cluster; therefore, taking snapshots should be performed as a regularly occurring maintenance operation. It is very important to run regular backups on the system_auth keyspace. See the following section for more information on the system_auth keyspace.
RHQ uses Cassandra's internal authentication and authorization. Usernames, passwords, and permissions are stored in the system_auth keyspace. If the data for the system_auth keyspace was corrupted in some way, such as residing on a failing disk, it is likely that clients (i.e., the RHQ server) would not be able to log in. It is therefore imperative to keep backups of the system_auth keyspsace.